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Annexes 

Annex C 

(informative) 

Wireless HiperLan-2 layer 



C.1 HiperLan-2 overview 
C.1.1 Design motivation 

The HiperLan~2 supported wireless interconnect is primarily intended to support wireless bridge attach- 
ments, as well as individual node atiachmenis, as illusu-ated in figured. Properties of the HiperLah-2 
Surreal interconnect are listed in table C.l and described in the remainder of this annex. . 
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Figure C.l — HiperLan-2 phase-1 topology 

C.2 Leaf bridge simplifications 
C.2.1 Design motivation 

Bus bridges can be simplified if one of the portals is known to be a leaf-bus portal; such bridges are called 
leaf-limited bridges. A leaf bus is defined to be a bus with only one bridge portal. An expected application 
for a leaf-limited bridge is to connect multiple cable-based Serial Bus interconnects to a common Surreal 
(Serial Bus like) backbone interconnect. 

Leaf-linlited bridges are sufficient for many applications and are attractive due to the simplicity implied by 
topological restrictions. 

C.2.2 Homogeneous limited-leaf bridge topologies 

A leaf-limited bridge is defmed as asymmetric bridge that has two portals, called lype-A and type-B. The 
type-A portal normally attached to a leaf bus (a bus with exactly one attached portal). A homogeneous leaf- 
bus topology has one branch bus and multiple leaf buses, as illustrated in figure C.2. 

In such limited homogeneous topologies, routing decisions are simple and listed below. 

1) Type- A portals. A type- A portal accepts packets addressed to itself or other buses, as follows: 
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Table C.1 — HiperLan-2 interconnect features 



Optionality 


Property 


o 

cc 


Description 


mandatory 


asynchronous formats 


1 


JdentiTier ano timesiamp are pre(>enoea lo eacn pacKei 


isochronous 


2 


Timestamp labels are prepended to each packet 


independent streams 


3 


( — TBD— Connection conflict resolution) 


reliable transmission 


4 


Maximum effective error rates (see B^?) 


maximum payload 


5 


Supports up-to S12-byte asynchronous-packet data payloads 


-?events?- 


6 


ROM change,.function change, attach, detach, phyld reused 


optiona] 


link-on requests 


n 
/ 


/\UlUirjaLiw LI allbpaiCIil, dciivciicu wiicii iiuuc lo ciw«(«wS9v!U 


robust events 


8 


Confirmed flow-controlled events supports (??) 


selective decode 


9 


Multiple ARP responses possible; first is accepted 


lime-of-death 


10 


Prepended to request and response packets 


pipelined 


11 


Other packets can be sent before first is acknowledged 


concurrent 


12 


Starts other packet transmissions before first one completes 
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Figure C.2— Homogeneous limited-leaf bridge topology 

a) Physical portal. Accepted if destmation_ID.busJd=3FF^^ and destination JlDAocalld-phyld. 

b) Virtual bus. Accepted and forwarded if destination_ID.busId\=3¥Fi^. 

2) Type-B portals. A type-B portal accepts packets addressed to it or the adjacent bus, as follows: 

a) Physical portal. Accepted if destination JD.busld=3¥F\^ and destination JD.localld-phy Id. 

b) Virtual portal. Accepted if destination J D. bus Jd-O00^(, and destination_ID.locaUd^phyJd. 

c) Selected bus. Accepted and forwarded if destination_lD.busld=phyId-^ 1 , 



These decoding rules are based on the assumption that transactions are predecoded by the producer, which 
replaces virtual local-bus addresses with their physical address equivalents. 

C.2.3 Heterogeneous bridge topologies 

Generalized (non leaf-limited) bridges are architecturally synimetric, with two lype-C portals. An illustrative 
topology, that contains leaf-limited as well as generalized bridges, as illustrated in figure C.3. 

An expected application for a leaf-limited bridge is to connect multiple cable-based Serial Bus interconnects 
to a common Surreal (Serial Bus like) backbone interconnect. Within this environment, portal routing 
decisions are simple, as listed below. 

] ) Type- A portals. A type-A portal accepts packets addressed to itself or other buses, as follows: 
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Figure C.3 — Heterogeneous bridge topology 

a) Physical portal. Accepied if destination JD.hus]d=3FFi^ and destination JDAocalld^phy Id. 

b) Virtual bus. Accepted and forwarded if destination_]D.busId\^3¥¥\^, 

2) Type-B portals. A type-B portal accepts packets addressed to it or the adjacent bus, as follows: 

a) Physical portal. Accepted if destination JD.busld^3¥¥i^ and destination JD.locaUd=^phyld. 

b) Virtual portal. Accepted if destination_JD,busJd=branchJd and destination_lD.iocalJd-phyId, 

c) Selected bus. Accepted and forwarded if destination_ID.busId~leqfBusId. 

C.2.4 Type-A bus resets 

To avoid use of possibly inconsistent slate, a leaf-bus reset has the side effect of assigning a new phyld to the 
adjacent portal, when this is not possible. When this is not possible, because the bus lacks this capability 
(Serial Bus) or because a phylD is reassigned (HiperLan-2), the branch-bus shall also be reset. A reset of the 
branch bus has the effect of resetting attached leaf buses. 

This simplified bus reset strategy eliminates the need to support quarantine bits when operating in a 
homogeneous limited-leaf topology. 

C.2.5 Prime portal responsibilities 

During net refresh operations, type-B portals observe whether other type-C portals are also attached. When 
no type-C portals are found, the lowesl-phyld type-B portal becomes the prime-alpha portal with a limited 
set of responsibilities, listed below: 

1) Subtractive decode. Nonexistent addresses are accepted and a rejection response is returned. 
Nonexistent addresses include the following: 

a) Mrtual node. Address destinationJD.busld^branchld and validldestination_ID,locaiJd]=^0, 

b) Physical node. Address destinationJD.busJd^3FFi^ and valid[destinationJDJocalJdl==0. 

c) Core buses. Address destination _lD,busld<6^ and valid[destination_ID.busId\^=Q, 

d) Other buses. Address destinationJlD.busId>-M. 

When a branch-bus lype-C portal is discovered, the type-B portals abstain from the prime portal selection 
process. The intent it to allow the use of more sophisticated lype-C bus-identifier assignment protocols. 



C.3 Illegal leaf-bus topologies 

A lype-A portal is designed to operate as the only portal on the bus. However, to ensure correct operation 
their behaviors is also defined in the presence of other portals. Their conflict resolution protocols are simple; 
the type-A nodes shall disable themselves when other portals are observed on their bus, listed below and 
illustrated in figure C.4: 

1) Redundant. When multiple type-A portals exist, all but the lowest phyld port shall be disabled. 

2) Conflicting. When a type-B or type-C portal exists, all lype-A portals shall be disabled. 
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Figure C,4 — Heterogeneous bridge topology 
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C.4 Special services 
C.4.1 Self-id services 

In addition to attached phyld information. HiperLan-2 provides supplemental information, listed below, for 
each of the 63-possible Serial Bus specified phylD addresses. 

1) EUI-64. The ElII-64 of the attached node. 

2) MAC-ID. The HiperLan-2-specified local-bus identifier for the node. 

3) Class. The following classification services simplify bus-bridge configuration services. 

a) Aware. This is a bridge-aware nonporta.l node 

b) Portal, type-A. The leaf-side portal of a leaf-limited bridge. 

c) Portal, type-B. The attach-side portal of a leaf-limited bridge (not supported in phasel). 

d) Portal, type-C. Either side of an non-leaf-limiied bridge (phase 2). 

C.5 Local ARP 

All HiperLan-2 packets are directed to another node based on that node's 8-bii MAC-ID address. Nodes are 
expected to cache recently used phyld-to-M AC-ID address translations. When no address exists, LARP is 
used, and the result of that LARP is cached for future use. 

C.6 Request-response services 

All HiperLan-2 communications are performed over logically independent point-to-point full-duplex 
connections. Since the lower-level protocols do not distinguish between requests and responses, and requests 
cannot block responses, acknowledgements allow requests to be "busied" at higher levels, as illustrated in 
figure C.5. 




Figure C-5— Shared partially acknowledg d request/response queues 
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C.7 Packet formats 

C.7.1 Asynchronous packet formats 

The HiperLan-2 asynchronous packet consists of a Serial Bus packet with a prepended quadlet, as illustrated 
in figure C.6. 
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request acknowledegment 
Figure C.6 — Encapsulated request/response subactions 

The 16-bit seconds and fraction fields are set by the free-running timer and represent the time in integer sec- 
onds and fraction seconds. The purpose of these fields is to specify the packet*s time-of-death, so that it can 
be safely discarded within the specified interval. 

The a bit is one when an acknowledge is requested (even though not busied); otherwise this bit shall be zero. 
The r bit shall be reserved. 

The 3'bii pt (packet thype) field differentiates between distinct packet types, as specified in table C.2. 

Table C.2 — Defined values 



Value 


Name 


Definition 


0 


UNACKNOWLEDGED 


Only busy acknowledgments are necessary 


1 


ACKNOWLEDGED 


An acknowledgment shall always be returned 


2-6 




Reserved 


7 


ACKNOWLEDGE 


Done acknowledge: should be discarded 



The trailing zero-pad bytes extend the packet to the next quadlet boundary, as is done on SerialBus. The 
remaining fields, including the 32-bit header_CRC and 32-bit data^CRC fields, are the same as those used 
on cable 1394. 

The acknowledge packet is a copy of the request and response packet, with the. exception of the rt field that 
is changed to identify the acknowledge packet and the b bit. The h bit is 1 if the packet was discarded and 
shold be retransmitted; otherwise this bit shall be zero. 
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C.7.2 Isochronous packet formats 



NOTE — If transmission of a source identifier is found to be necessar>'. the reserved field will be used for this purpose 

Most of the HiperLan-2 isochronous packet is the same as 1394, but a small portion of these packets are not, 
as illustrated in figure C7. 
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Figure C.7 — Isochronous packet format 

A smaller 12-bit datajength field is sufficient to support up to 16Mbyte/sec data transfers, beyond the 
limitations or current and forseen physical layers. The 13-bii cycle^numher time-stamp value identifies the 
isochronous cycle in which the isochronous packet was first accepted by the bridge. 

The trailing zero-pad bytes extend the packet to the next quadlet boundary, as is done on SerialBus. No 
32-bit header JCRC is provided on isochronous packets (transport-level ECC covers each isochronous 
packet segment). The 32-bit datajCRC field (the same as that used on cable 1394) is provided to reliably 
detect segment-lost conditions. 

A porfion of this header sometimes contains a time stamp, that must be modified as these packets pass 
through bridges (see D.2.1). These fields are not modified when passing from Serial Bus to HiperLan-2, but 
supplements the isochronous packet with a cycle_number time stamp. The CIP-header lime stamps are 
adjusted when these packets pass from HiperLan-2 to Serial Bus. 

The CIP header also contains a 6-bit sid (source identifier) field. Since this information is implied by the 
isochronous channel number, this field remains unchanged when the isochronous packet passes from 
Serial Bus to HiperLan-2. When passing from HiperLan-2 to SerialBus, this field is set to identify the 
Serial Bus source portal. 



C.7.3 GASP packet formats 



The GASP packet format is the same as specified for SerialBus, with the exception that no header CRC is 
transported, as iliusu^ated in figure C.8. 
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Figure C.8 — HiperLan-2 GASP packet format 
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C.7.4 Isochronous delivery times 

Data delivered in frames, where frames are sent periodically approximately once every 2ms. The 2ms clock 
is not necessarily synchronized to the net's 125ms isochronous cycle, as illustrated in figure C.9. This 
implies that each frame may contain 8 or 9 isochronous packets, depending on relative timings of 
HiperLan-2 frames and isochronous cycles on the interface. 
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Figure C.9 — Clock synchronization facilities 

Hiperlan-2 clock distribution is done once v^iihin every 2ms frame. Time estimation involves latching the 
local-time value at the beginning of each frame, on all nodes. The clock-masler copies its sampled time into 
a "packet" that is placed within the following frame (not illustrated). The clock-slave nodes compare iheir 
sampled time to the "packet" lime, to estimate the en-or between clock-master and clock-slave clocks. The 
error value is latched (when stable) and used to compensate for the clock-slave's node timer, as illustrated in 
figure C.IO. 
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Figure C.10 — Per-frame time adjustments 
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C.7.5 Isochronous services 

Timely delivery in the presence of arbiuary request and response traffic. 

1) IRM (isochronous resource manager). The IRM services, which are available lo nodes and portals, 
provides a pass/fail indication and channel number lo isochronous resource requests. 

C.7.6 Bus-local query services 

Query services thai are provided include the following: 

1 ) LARR Local address resolution protocols return the MAC JD of the local consumer. 
Two types of addresses may be broadcast in the ARP request, as follows: 

a) Local ID. A 6-bit phyld, corresponding a local-bus node or portal that accepts this subaciion. 

b) Remote ID. A 10-bit busid, corresponding to the portal which maps this remote-bus address. 

2) Events. Information contained within a bus reset is broadcast to others: 

a) Attached. A new node has been assigned to a previously unused phyld address. 

b) Detached. An existing node no longer responds to a previously used phyld address. 

c) Conflict. A new node has been assigned a previously used phyld 
(to ensure data integrity, a new bus_ID is assigned). 

d) Revised. An adjacent node has received a revised (previously unused) phylD assignment. 

e) ROM change. A local-bus node's ROM contents may have changed. 

TBD — 

How are query transport errors detected? What happens after an error? How is the delivery confirmed? 
C.8 Effective packet-transmission error rates 

Estimates of the effective HiperLan-2 error rates are documented in table C.3. The are raw bit-error rates and 
have not been adjusted for expected packet-sizes.. 



Table C.3 — Worst-case error rate estimates 



TVafBc 


Error type 


Value 




Description 


Asynchronous 


detected-payload 




1 


Effective daia_error response rate 




detected -header 


(10-1^ 


2 


Effective asynchronous packet-loss rate 




undetected 


(10-20) 


3 


Effective asynchronous packet-corruption rate 


GASP packets 


detecied-payload 


(io-») 


4 


Effective indication-lost rate 


(TBD) 


deiected-header 


(10-8) 


5 


Effective payload-loss rate 




undetected 


(10-^8) 


6 


Effective false-indication rate 


Isochronous 


detected-payload 


(10**^) 


7 


Effective data_error interpretation rate 




delected -header 


(10-12) 


8 


Effective isochronous packet-loss rate 




undetected 


(10*22) 


9 


Effective isochronous packet-conuption rate 
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